System and methd for common information model object manager proxy interface and management

ABSTRACT

A system, method and computer program for transmitting and receiving information between computer systems. This is accomplished using a common information model object manager (CIMOM) proxy that serves to receive and transmit information from one computer on the network to another. The CIMOM proxy relies on both managed system providers and client applications to register with the CIMOM proxy. Once registered the client application may request information and receive it from managed system providers.

FIELD

[0001] The invention relates to a system and method for commoninformation model object manager (CIMOM) proxy interface and management.More particularly, the present invention utilizes a CIMOM proxy toenable and simplify communications between remote providers and commoninformation model (CIM) client applications.

BACKGROUND

[0002] In the rapid development of computers many advancements have beenseen in the areas of processor speed, throughput, communications, andfault tolerance. Initially computer systems were standalone devices inwhich a processor, memory and peripheral devices all communicatedthrough a single bus. Later, in order to improve performance, severalprocessors were interconnected to memory and peripherals using one ormore buses. In addition, separate computer systems were linked togetherthrough different communications mechanisms such as, shared memory,serial and parallel ports, local area networks (LAN) and wide areanetworks (WAN). Further, with the development of the Internet andadvancements in cellular and wireless communications, it is now possiblefor computers to communicate without the use of wires, such as providedby the public switched telephone network (PSTN), over great distances.

[0003] In order to facilitate communications between providers ofdifferent hardware and software, schemas and standards have beenestablished. One such schema is the common information model (CIM) whichis a common data model of an implementation-neutral schema fordescribing the overall management of information in a network/enterpriseenvironment. FIG. 1 is an example implementation of a network in whichcommunications is established utilizing CIM. In this example, provider A40 in managed system A 10 through CIM object manager (CIMOM) 50communicates to CIM client application 140 in CIM client 100, CIM clientapplication 150 in CIM client 110, and CIM client application 160 in CIMclient 120. Further in this example, provider B 60 in managed system B20 through CIMOM 70 communicates to CIM client application 140 in CIMclient 100, CIM client application 150 in CIM client 110, and CIM clientapplication 160 in CIM client 120. Still further in this example,provider C 80 in managed system C 30 through CIMOM 90 communicates toCIM client application 140 in CIM client 100, CIM client application 150in CIM client 1 10, and CIM client application 160 in CIM client 120. Itshould be noted that managed system A 10, managed system B 20, managedsystem C 30, CIM client 100, CIM client 110, and CIM client 120 are alldepicted as independent computer systems or processors communicatingwith each other over a LAN, WAN, PSTN or any other suitablecommunications mechanism. It should also be noted that CIMOM 50, 70, 90comprise all software, logic and hardware required for communications.

[0004] However, the requirement that separate copies of CIMOM 50,70,90in each management system requires the use of an enormous amount ofmemory throughout all the systems. Further, there is no limit on thenumber of management systems and CIM client applications that may existwithin a network. Further, each management system would be required tonot only utilize its own memory to store each CIMOM but also its ownprocessor to execute the logic involved in CIMOM.

[0005] Therefore, what is required is a system and method whereby theneed for each management system to have its own copy of CIMOM iseliminated. This system and method should also minimize the processortime required to establish communications with CIM client applications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The foregoing and a better understanding of the present inventionwill become apparent from the following detailed description ofexemplary embodiments and the claims when read in connection with theaccompanying drawings, all forming a part of the disclosure of thisinvention. While the foregoing and following written and illustrateddisclosure focuses on disclosing example embodiments of the invention,it should be clearly understood that the same is by way of illustrationand example only and the invention is not limited thereto. The spiritand scope of the present invention are limited only by the terms of theappended claims.

[0007] The following represents brief descriptions of the drawings,wherein:

[0008]FIG. 1 is an example of the prior art in common information model(CIM) communications;

[0009]FIG. 2 is a systems diagram of a communications network using aproxy CIMOM to facilitate communications between managed systems and CIMclient applications in an example embodiment of the present invention;

[0010]FIG. 3 is a flowchart of a remote provider registering with a CIMlookup service and determining the location of the proxy CIMOM in anexample embodiment of the present invention;

[0011]FIG. 4 is a flowchart of the logic executed by the CIMOM discoverymodule shown in FIG. 6 in an example embodiment of the presentinvention;

[0012]FIG. 5 is a flowchart of the interaction between the CIM clientapplication and the proxy CIMOM in an example embodiment of the presentinvention;

[0013]FIG. 6 is a data flow diagram between the proxy CIMOM, the remoteprovider, the CIM lookup service and the CIM client; and

[0014]FIG. 7 is an alternate configuration of the systems diagramprovided in FIG. 2 depicting possible hardware that may be used.

DETAILED DESCRIPTION

[0015] Before beginning a detailed description of the subject invention,mention of the following is in order. When appropriate, like referencenumerals and characters may be used to designate identical,corresponding or similar components in differing figure drawings.Further, in the detailed description to follow, exemplarysizes/models/values/ranges may be given, although the present inventionis not limited to the same. As a final note, well-known components ofcomputer networks may not be shown within the FIGS. for simplicity ofillustration and discussion, and so as not to obscure the invention.

[0016]FIG. 2 is a systems diagram of a communications network using aproxy CIMOM 210 in a server 200 to facilitate communications betweenmanaged systems A 10, managed systems B 20, and managed systems C 30 andCIM client applications 100, 110, and 120 in an example embodiment ofthe present invention. As would be appreciated by one of ordinary skillin the art, the proxy CIMOM 210 does not need to be contained in aseparate processor or computer system. The proxy CIMOM 210 may reside inany server, processor, or computer system in which it is a commonresource for use by the other managed systems in the network.

[0017] Still referring to FIG. 2, communications between, for example,provider A 40 and CIM client application 140 would occur through server200 using proxy CIMOM 210. The precise communications mechanism usedbetween any of the systems shown in FIG. 2 would include any form ofcommunications utilized to communicate from one computer to another.This would include both serial and parallel communications over, but notlimited to, twisted pair, coax cable, fiber optic cable and all forms ofwireless communications. Provider A 40 would also communicate to CIMclient application 150 and CIM client 160 through proxy CIMOM. In asimilar manner provider B 60, provider C 80 would communicate to CIMclient application 140, 150 and 160 through proxy CIMOM 210. The precisemanner by which the proxy CIMOM 210 operates will be discussed infurther detail in reference to FIGS. 3 through 6 ahead.

[0018]FIG. 3 is a flowchart of a remote provider 750, shown in FIG. 6,registering with a CIM lookup service 700, shown in FIG. 6, anddetermining the location of the proxy CIMOM 200 in an example embodimentof the present invention. The remote provider 750, shown in FIG. 6, maybe provider A 40, provider B 60 or provider C 80 shown in FIG. 2 or someother provider not shown.

[0019] Still referring to FIG. 3, execution begins by the remoteprovider 750, such as provider A 40, shown in FIG. 2, registering with aCIM lookup service 700 in operation 300. In operation 300, thisregistration process would entail the remote provider 750 transmittingcertain information to CIM lookup service 700. This information wouldinclude the remote provider 750 name, the system identification number,such as an Internet Protocol (IP) address, the communications protocol,and the CIM management object format (MOF) file. The communicationsprotocol would include additional parameters such as a TCP/IP(Transmission Control Protocol/Internet Protocol) Port number or a JAVAremote method invocation object. The MOF file would be used by the ProxyCIMOM 200 to facilitate communications.

[0020] Still referring to FIG. 3, processing then proceeds fromoperation 300 to operation 310. In operation 310, the remote provider750 then queries the CIM lookup service 700 for information regardingthe proxy CIMOM 200. This information would include the proxy CIMOMsystem identification such as the IP address for the proxy CIMOM 200.This information would further include the communications protocol thatshould be used when communicating to the proxy CIMOM 200, such as TCP/IPor Java remote method invocation. Thereafter, processing proceeds tooperation 320, where it is determined if the proxy CIMOM 200 hasregistered itself with the CIM lookup service 700. If the proxy CIMOM200 has not registered itself with the CIM lookup service 700 thenprocessing proceeds to operation 330. In operation 330, the remoteprovider 750 registers at the request of the CIM lookup service 700, asa result of receiving a negative response from the CIM lookup service inoperation 320, for a proxy CIMOM registration event notification. Inoperation 340, the registration of the proxy CIMOM 200 has occurred bythe proxy CIMOM 200 registering with the CIM lookup service 700 causingthe generation of a proxy CIMOM registration event which notifies theremote provider 750 of the registration event. This registration eventcauses the transmission of proxy CIMOM system identification, such as IPaddress, and the communication protocol to the remote provider 750.Thereafter, processing proceeds to operation 350 from either operation340 or from operation 320. In operation 350, the remote provider 750stores the proxy CIMOM information for future remote provider eventdelivery in either the case that the proxy CIMOM 200 should change itsregistration information or should the proxy CIMOM 200 register for thefirst time with the CIM lookup service 700. The registration processshown in FIG. 3 then terminates.

[0021]FIG. 4 is a flowchart of the logic executed by the CIMOM discoverymodule 710, shown in FIG. 6, in an example embodiment of the presentinvention. The CIMOM discovery module 710 begins execution in operation400 where the proxy CIMOM 200 registers with the CIM lookup service 700and transmits the appropriate information required. This informationwould include the proxy CIMOM 200 system identification such as, but notlimited to, its system identification number, the IP address andadditional parameters. Processing then proceeds to operation 410 wherethe proxy CIMOM 200 registers with the CIM lookup service 700 for remoteprovider registration event notification discussed in further detail inreference to FIG. 5. Thereafter in the discovery module 710, inoperation 420, the proxy CIMOM 200 queries for information relating toeach remote provider 750. This information would include the remoteprovider=s 750 name, the remote providers=s 750 system identification,the communication protocol to be used, and the MOF file. The remoteprovider=s system identification may be, but not limited to, an IPaddress. The communication protocol may be, but not limited to TCP/IPincluding a port number or a JAVA remote method invocation object.

[0022] Still referring to FIG. 4, processing in the discovery module 710then proceeds to operation 430 where the MOF file is loaded into a newname space in the proxy CIMOM 200 along with the information transmittedin operation 420. This information would include the remote provider=s750 name, the remote providers=s 750 system identification, thecommunication protocol to be used. Thereafter, in operation 440,whenever a new remote provider 750 registers with the CIM lookup service700, the CIM lookup service 700 will notify the proxy CIMOM 200 of thenew remote provider. This notification would include the remoteprovider=s 750 name, the remote providers=s 750 system identification,the communication protocol to be used, and the MOF file. Thereafter, thediscovery module 710 would loop back to and repeat operation 430. Thisprocess continues until such time as the network or the proxy CIMOM 200are taken offline.

[0023]FIG. 5 is a flowchart of the interaction between the CIM clientapplication 760, shown in FIG. 6, and the proxy CIMOM 200, shown inFIGS. 2 and 6, in an example embodiment of the present invention. Itshould be noted that the CIM client application 760 may be any CIMclient application 140, 150, and 160 shown in FIG. 2. Processing beginsin operation 500 where the CIM client application 760 queries the CIMlookup service 700 for information related to the proxy CIMOM 200 andrequired to connect the CIM client application 760 to the proxy CIMOM200. This information includes the proxy CIMOM 200 identificationnumber, such as Internet Protocol (IP) address, and the communicationsprotocol. The communications protocol would include additionalparameters such as a TCP/IP port number or a JAVA remote methodinvocation object. Thereafter, processing proceeds to operation 510where it is determined if the proxy CIMOM 200 has registered with theCIM lookup service 700.

[0024] Still referring to FIG. 5, if the proxy CIMOM 200 has notregistered with the CIM lookup service 700, then processing proceeds tooperation 520 where the CIM client application 760 registers with theCIM lookup service 700 for a proxy CIMOM 200 registration eventnotification and the CIM client application 760 then waits for the eventnotification to take place. Once the proxy CIMOM 200 registration eventnotification takes place by the proxy CIMOM 200 registering with the CIMlookup service, as previously discussed, then in operation 530 the CIMlookup service 700 transmits the proxy CIMOM 200 identification number,such as Internet Protocol (IP) address, and the communications protocol.The communications protocol would include additional parameters such asa TCP/IP port number or a JAVA remote method invocation object.Processing then proceeds to operation 540 from operation 530 or fromoperation 510, if the proxy CIMOM 200 has registered with the CIM lookupservice 200. In operation 540, the CIM client application 760 connectsto the proxy CIMOM 200 via the connection authentication module (CAM)720 and supplies a user name and password to the CAM 720.

[0025] Still referring to FIG. 5, in operation 550, if the CIM clientprovides a correct user name and password then processing proceeds tooperation 560, otherwise processing returns to operation 540 which isrepeated until a correct user name and password is entered. As would beappreciated by one of ordinary skill in the art, after some number offailed attempts are made the CAM 720 would simply bar further attemptsfor the CIM client application 760 to receive authentication during thissession. However, if it is determined that the user name and passwordare valid, in operation 550, then processing proceeds to operation 560.In operation 560, the proxy CIMOM 200 returns the proxy CIMOM 200 namespaces which may include the address or identification of the remoteproviders 760. As previously discussed the remote providers 760 may beany of the managed systems 10, 20, and 30 shown in FIG. 2.

[0026] Still referring to FIG. 5, thereafter in operation 570, it isdetermined if the CIM client application 760 desires to receiveasynchronous remote provider 750 events. If the CIM client application760 desires to receive asynchronous remote provider 750 events thenprocessing proceeds to operation 580 where the CIM client application760 registers with the event module 740 contained within the proxy CIMOM200. The event module is given the CIM client application 760 name, theCIM client application 760 system identification, such as the IPaddress, and the communication protocol to use. The communicationprotocol may be, but not limited to TCP/IP, including a port number, ora JAVA remote method invocation object. Thereafter, processing proceedsto operation 590 from either operation 580 or operation 570 in the casethat the CIM client application 760 does not desire to receiveasynchronous remote provider 750 events.

[0027] Still referring to FIG. 5, in operation 590, the CIM clientapplication 760 selects the name space of the remote provider 750 ofinterest. Thereafter, in operation 600, the CIM client application 760requests data of the particular CIM class in the selected name spaceassociated with the remote provider 750 from the proxy CIMOM 200. Inoperation 610, the request processing module (RPM) 730 in the proxyCIMOM 200 queries the remote provider 750 for delivery of the CIM classdata requested by the CIM client application 760. Thereafter, processingproceeds to operation 620 where the proxy CIMOM 200 receives theasynchronous events and data from the remote provider 750 and thereafterdelivers the data to the CIM client application 760 which has registeredfor these particular events. It should be noted that more than one CIMclient application 760, such as managed systems A 10, managed system B20, or managed system C 30, may request the same data from a remoteprovider 750.

[0028]FIG. 6 is a data flow diagram illustrating the flow of informationbetween the proxy CIMOM 200, the remote provider 750, the CIM clientapplication 760, and the CIM lookup service 700. FIG. 6 contains modulesrepresenting software, commands, firmware, hardware, instructions,computer programs, subroutines, code and code segments previouslydiscussed in reference to the example flowcharts FIGS. 3 through 5. Themodules shown in FIG. 6 may take any form of logic executable by aprocessor, including, but not limited to, programming languages, such asC++. Typically, a CIM client application 760 will attempt to discoverthe location of the proxy CIMOM 200 by accessing and registering with aCIM lookup service 700. The proxy CIMOM 200 also accesses the CIM lookupservice 700 to discover the location of the remote providers 750. TheCIM client application 760 is provided with the location (address) ofthe proxy CIMOM 200. The CIM client application 760 then queries theproxy CIMOM 200 for remote provider 750 CIM data. The proxy CIMOM 200queries the remote provider 750 for the CIM data. The remote provider750 then delivers the data to the proxy CIMOM 200 and in turn the proxyCIMOM 200 delivers the remote provider 750 data to the CIM clientapplication 760. Prior to access and delivery of such remote provider750 data, the remote provider 750 must register with a CIM lookupservice 700 which in turn updates the proxy CIMOM 200 with the locationof the remote provider 750.

[0029]FIG. 7 is an alternate configuration of the systems diagramprovided in FIG. 2 depicting possible hardware that may be used. FIG. 7contains a proxy CIMOM 200 server connected through a LAN or WAN to amanaged system A 10, a managed system B 20, a managed PDA system 810,and a server used for the CIM lookup service 700. In addition, FIG. 7illustrates a connection to LAN, WAN or wireless access 830 to the proxyCIM 200. This WAN or wireless access 830 may be through anycommunication means that allows at least two computer systems tocommunicate with each other. This wireless access 830 or WAN may be acellular telephone network or a satellite telephone network. Thepersonal digital assistant (PDA) 810 is a managed system like managedsystem A 10. A remote provider runs on the PDA providing the manageddata of the PDA to the proxy CIMOM. In addition, a laptop communicatingthrough a cellular phone may act as a CIM client application 760.Therefore, the hardware utilized to implement the embodiments of thepresent invention is not intended to limit the present inventionstrictly to that herein described.

[0030] The benefit resulting from the present invention is that asimple, reliable, fast system and method is provided for computers andprocessors to communicate to each other. Further, the sending andreceiving computers require the use of minimal space and processor timeto send and receive information through the use of a proxy CIMOM.

[0031] While we have shown and described only a few examples herein, itis understood that numerous changes and modifications as known to thoseskilled in the art could be made to the example embodiment of thepresent invention. Therefore, we do not wish to be limited to thedetails shown and described herein, but intend to cover all such changesand modifications as are encompassed by the scope of the appendedclaims.

1. A system for communicating component management data betweencomputers in a network, comprising: a plurality of remote managedsystems comprising one or more information providers to supply systemmanagement data from one or more components; a plurality of clientmanagement applications; an object manager, connected to the pluralityof remote managed systems and to the plurality of client managementapplications, to store information models of the components of one ormore of the managed systems, and to relay requests for data between theinformation providers and client management applications; and a lookupservice, communicatively coupled with the plurality of remote managedsystems, the plurality of client management applications, and the objectmanager, to discover the locations of the information providers and ofthe object manager, and to register the remote information providers andthe client management applications with the object manager.
 2. Thesystem recited in claim 1, wherein the object manager further comprises:a connection authentication module to authenticate the client systemsmanagement applications by checking a client management application username for a match with a plurality of user names entered into a filelocated on the object manager by the lookup service.
 3. The systemrecited in claim 1, wherein the object manager further comprises: adiscovery module to register the the object manager with the lookupservice and to determine the locations of the plurality of remotemanaged systems.
 4. The system recited in claim 1, wherein the objectmanager further comprises: a request processing module to query aselected remote information provider for information requested by aquerying client management application.
 5. The system recited in claim1, wherein the object manager further comprises: an event module toreceive information from a selected remote information provider and totransmit the information to a querying client management application. 6.The system recited in claim 5, wherein a client management applicationrequests that asynchronous remote information provider events bereceived from a selected remote information provider by transmitting tothe event module the client management application identifier and aselected communication protocol.
 7. The system recited in claim 4,wherein a remote information provider registers with the object managerby transmitting to the lookup service an information provideridentifier, a selected communication protocol, and information regardingcorresponding components which the lookup service relays to the objectmanager.
 8. A method of communicating component management data betweencomputers in a network, comprising: storing information models ofcomponents of a plurality of managed systems in an object manager;registering with the object manager via a plurality of remoteinformation providers from a plurality of managed systems and aplurality of client management applications sending information to alookup service; discovering the location of the object manager by thelookup service and transmitting the registration information receivedfrom the plurality of remote information providers and the plurality ofclient management applications to the object manager; transmitting thelocation of the object manager to the plurality of remote informationproviders and to the plurality of client management applications;requesting information of a selected remote information provider by aquerying client management application transmitting a request to theobject manager; relaying the request to the selected remote informationprovider with the object manager; and transmitting the information tothe querying client management application upon receipt by the objectmanager.
 9. The method recited in claim 8, wherein relaying the requestto the selected remote information provider with the object manager,further comprises: checking a database contained in the object managerto determine the location of the selected remote information provider;and transmitting the request for information to the selected remoteinformation provider.
 10. The method recited in claim 9, whereinchecking the database contained in the object manager to determine thelocation of the selected remote information provider, further comprises:queuing the request for information in a file when a match for theselected remote information provider cannot be found in the database.11. The method recited in claim 10, wherein registering with the objectmanager by a remote information provider, further comprises: checkingthe file containing the queued requests for information to determinewhether a request for information corresponding to the remoteinformation provider exists in the file; and transmitting the requestfor information to the remote information provider upon completing theregistration of the remote information provider.
 12. The method recitedin claim 8, wherein registering with the object manager by a clientmanagement application sending information to a lookup service, furthercomprises: transmitting a client management identifier and a selectedcommunication protocol to the lookup service; and relaying the clientmanagement application identifier and the selected communicationprotocol to the object manager by the lookup service.
 13. The methodrecited in claim 8, wherein registering with the object manager by aremote information provider sending information to a lookup service,further comprises: transmitting a remote information provideridentifier, information regarding corresponding components, and aselected communication protocol to the lookup service; and relaying theremote information provider identifier, the component information, andthe selected communication protocol to the object manager by the lookupservice.
 14. A computer program embodied on a computer readable mediumexecutable by a computer for communicating component management databetween computers in a network, comprising: storing information modelsof the components of a plurality of managed systems in an objectmanager, registering with an object manager via a plurality of remoteinformation providers from a plurality of managed systems and aplurality of client management applications sending information to alookup service; discovering the location of the object manager by thelookup service and transmitting the registration information receivedfrom the plurality of remote information providers and of the pluralityof client management applications to the object manager; transmittingthe location of the object manager to the plurality of remoteinformation providers and to the the plurality of client managementapplications; requesting information of a selected remote informationprovider by a querying client management application transmitting therequest to the object manager; relaying the request to the selectedremote information provider with the object manager; and transmittingthe information to the querying client management application uponreceipt by the object manager.
 15. The computer program recited in claim14, wherein relaying the request to the selected remote informationprovider with the object manager, further comprises: checking a databasecontained in the object manager to determine the location of theselected remote information provider; and transmitting the request forinformation to the selected remote information provider.
 16. Thecomputer program recited in claim 15, wherein checking the databasecontained in the object manager to determine the location of theselected remote information provider, further comprises: queuing therequest for information in a file when a match for the selected remoteinformation provider cannot be found in the database.
 17. The computerprogram recited in claim 16, wherein registering with the object managerby a remote information provider, further comprises: checking the filecontaining the queued requests for information to determine whether arequest for information directed to the remote information providerexists in the file; and transmitting the request for information to theremote information provider upon completing the registration of theremote information provider.
 18. The computer program recited in claim14, wherein registering with the object manager by a client managementapplication sending information to a lookup service, further comprises:transmitting a client management application identifier and a selectedcommunication protocol to the lookup service; and relaying the clientmanagement application identifier and the selected communicationprotocol to the object manager.
 19. The computer program recited inclaim 14, wherein registering with the object manager by a remoteinformation provider sending information to a lookup service, furthercomprises: transmitting a remote information provider identifier,information regarding corresponding components, and a selectedcommunication protocol to the lookup service; and relaying the remoteinformation provider identifier, the component information, and theselected communication protocol to the object manager by the lookupservice.
 20. The computer program of claim 19, wherein transmittinginformation regarding managed system components corresponding to theinformation provider comprises transmitting a CIM Managed Object Format(MOF) file.
 21. The system of claim 1, wherein the object manager storesinformation about the components of the managed systems according to theCommon Information Model (CIM) specification and schema.
 22. The systemof claim 1, wherein the lookup service is a CIM lookup service.
 23. Thesystem of claim 1, wherein the managed systems are personal computers24. The system of claim 7, wherein the information model is a CIMManaged Object Format (MOF) file.
 25. The method of claim 8, whereinstoring information models of the components of a plurality of managedsystems comprises storing CIM models of the components.
 26. The methodof claim 13, wherein transmitting information regarding managed systemcomponents corresponding to the information provider comprisestransmitting a CIM Managed Object Format (MOF) file.
 27. The computerprogram of claim 14, wherein storing information models of thecomponents of a plurality of managed systems comprises storing CIMmodels of the components.